If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
Facing a new issue today regarding the IP Information Tool where access to some of the non-admin information does not show up in the Special:Contributions page for an IP as it did before. That page now only shows "Version", "Active blocks", and "Contributions". Oddly, the country (not city) location still pops up on the watchlist preview, even though it does not show on the Contributions page. Anyone else seeing similar? Best, CMD (talk) 08:00, 15 May 2024 (UTC)[reply]
The IP information drop down has been returning no information for me other than the version (IPv4 vs. IPv6), local block info and contribs for the last two days. It's like it can't access any of the data from whichever database it draws from. Every other field simply states "not available".-- Ponyobons mots 21:43, 15 May 2024 (UTC)[reply]
And regarding my odd note on watchlist preview, this only happens sometimes, with even different edits from the same IP showing me country location in one instance but not another. CMD (talk) 01:50, 16 May 2024 (UTC)[reply]
Further learning, I can refresh the same IP contributions page repeatedly and sometimes it will show me the country, sometimes it will show no access. CMD (talk) 03:25, 16 May 2024 (UTC)[reply]
Can someone link a page where this has recently happened to them, so that I can try to reproduce? –Novem Linguae (talk) 07:15, 16 May 2024 (UTC)[reply]
Thanks, I'm able to reproduce. According to https://phabricator.wikimedia.org/T363118#9804312, "not available" is case #2. This means Spur/Maxmind doesn't have that data. Looking at these fields, they're all populated by Spur. Maxmind and Spur have different coverage, so we may have a location for an IP but no other data for it.. So that one is not a bug and they have no plans to patch it, it looks like. –Novem Linguae (talk) 15:56, 16 May 2024 (UTC)[reply]
I don't understand how that data was available consistently for all IPs, then suddenly is missing for nearly all of them. It renders the entire IP contribs drop down useless. Oh well.-- Ponyobons mots 16:13, 16 May 2024 (UTC)[reply]
Someone just commented in the ticket that they think it's happening way more than it used to and they think something is broken. So it may be a bug after all. Here's hoping the devs figure it out. –Novem Linguae (talk) 16:47, 16 May 2024 (UTC)[reply]
Dark mode is available in Vector 2022 as a beta feature[edit]
Show what we've built very early. The earlier you are involved, the more your voices will be reflected in the final version
Get your help with flagging bugs, issues, and requests
Work with technical editors to adjust various templates and gadgets to the dark mode
Known limitations
Dark mode is only available for logged-in users: on desktop as a beta feature, and on mobile in the advanced mode.
Gadgets may initially not work well with dark mode and may have to be updated.
Our first goal is making dark mode work on articles. Special pages, talk pages, and other namespaces (including Wikipedia) have not been updated to work in dark mode yet. We have temporarily disabled dark mode on some of these pages.
What we would like you to do
Our request to you is exactly the same as previously:
If no relevant example is available or you're not sure of the fix, contact us
If you have a bug report for dark mode that is not related to templates
Take a screenshot of what you are observing.
Contact us. If possible, please write down your browser version and operating system version.
When most issues are solved, we'll be able to make the dark mode available for readers on both desktop and mobile. Go to the Accessibility for Reading project page and the FAQ page to see more information about the basics of this project. Thank you! SGrabarczuk (WMF) (talk) 21:47, 15 May 2024 (UTC)[reply]
I don't know if this was the right move. Tons of pages still look like garbage (shoutout Special:Watchlist)—the theme is definitely not ready for use by non-technical editors. It wouldn't be too bad if you had made a seperate beta option for it—because you've clumped it in with Accessibility for Reading a couple people have gone on the Discord confused. Snowmanonahoe (talk·contribs·typos) 23:54, 15 May 2024 (UTC)[reply]
"Fixing" it is as simple as setting your personal chosen theme to light mode.
As for tons of pages, I just got separate word that OOUI interfaces don't support light mode (currently/ever?), which is why Watchlist has light elements. Perhaps it shouldn't be displaying as dark. Izno (talk) 00:08, 16 May 2024 (UTC)[reply]
Articles too. Along with interface pages, editnotices, syntax highlighting, half the mboxes... Snowmanonahoe (talk·contribs·typos) 00:27, 16 May 2024 (UTC)[reply]
The point is for editors to find these things. Might as well drop logged users in and let them make the two button presses to find a different, less-painful choice. Izno (talk) 00:41, 16 May 2024 (UTC)[reply]
Exactly, there is no magic fairy dust for some of this, just grunt work to fix the pages and templates that never had to account for a darkmode. —TheDJ (talk • contribs) 14:56, 16 May 2024 (UTC)[reply]
We do have a long-term solution for OOUI fixes that is in development right now. We hope to have it ready within the next couple of weeks. In the meantime however, pages like Watchlist and should be displaying in light mode so this is a bug. We're tracking it in phab:T365084 and should have a fix out later today. OVasileva (WMF) (talk) 07:36, 16 May 2024 (UTC)[reply]
@SGrabarczuk (WMF): Is there really a plan to take over the right 1/4 of screen with a "settings" panel every time someone opens a page in a new private tab, or clears cookies, or switches to a new language, or doesn't realize what the "hide" button does? Or is that just so in-your-face during the testing phase? Suffusion of Yellow (talk) 02:01, 16 May 2024 (UTC)[reply]
Hey @Suffusion of Yellow - thanks for the question. In general, we think this is the most effective way to launch the new menu and be able to inform users about it. It removes the necessity to add additional modals or notices that say "New menu available!" or "Dark mode available", which would otherwise show on every pageview. So, the current plan is to keep the menu open by default for the wider release as well for all logged-in and logged-out users. Then, after the release, we can look at the data to gauge whether we need to keep it open as default, or collapse, and when. OVasileva (WMF) (talk) 07:40, 16 May 2024 (UTC)[reply]
Why can't it be on the left side, with the TOC? Or better yet, just put a plain-text link at the top? I mean, registered users have already been able to find the "preferences" link for 20 years now. Right when I open up testwiki:LOREM IPSUM (or any page with a TOC) on my phone in a new private tab, then switch to the desktop site, about half my screen is whitespace, and the text is squished into a narrow little strip in the middle. It's unusable until I hide the settings column
People are reading a website, not installing software. There shouldn't be a "setup" stage before they can get down to the business of looking up that one little fact. The defaults should at least be usable. Suffusion of Yellow (talk) 17:11, 16 May 2024 (UTC)[reply]
@SGrabarczuk (WMF):https://night-mode-checker.wmcloud.org/ appears to only be for the mobile version. Is there is desktop report? Also, the beta is only for Vector 2022. Many editors still use legacy vector or other skins, will the new feature be moved to any other skin besides Vector 2022? How does the new feature compare to the dark mode gadget that is currently available? RudolfRed (talk) 03:31, 16 May 2024 (UTC)[reply]
This dark mode is only going to be supported on Vector 22 and Minerva so far as I know. Izno (talk) 03:54, 16 May 2024 (UTC)[reply]
The main idea of the new feature is that it doesn't invert colors that are not known to be invertable. This causes the colors on Pantone for example to not be distorted. Snowmanonahoe (talk·contribs·typos) 11:43, 16 May 2024 (UTC)[reply]
For some reason, if I go to the page history of any enwiki page, the undo button now says "cin gbere le" instead of "undo", as shown in the screenshot here. It just started happening today all of a sudden. Anyone else had this problem?
Note: the button actually still works, I just tested it here, it's just the button text that's different. — AP 499D25(talk) 08:41, 16 May 2024 (UTC)[reply]
Short answer, don't use en-gb. Long answer - its upstream vandalism at translatewiki of the MediaWiki:Editundo message in the en-gb language. Language (Warning: Selecting a language other than 'en - English' will prevent you from seeing localized parts of the interface on the English Wikipedia, and you may see inaccurate external translations.): — xaosfluxTalk 09:04, 16 May 2024 (UTC)[reply]
The upstream vandalism seems to have been cleared, but now you will have to wait for sync. Or just change to en. — xaosfluxTalk 09:09, 16 May 2024 (UTC)[reply]
I created MediaWiki:Editundo/en-gb with "undo". Presumably that can be deleted when it synchronises — Martin (MSGJ · talk) 10:01, 16 May 2024 (UTC)[reply]
I see! Lol. Indeed, I have my interface language set to en-gb. Though I'm not sure how a protected page like that got vandalised. I guess it's unprotected on the translatewiki. — AP 499D25(talk) 09:16, 16 May 2024 (UTC)[reply]
It's not quite the most aggressive action by the Provisional Change to EN Brigade that I've ever seen, but it's up there. DuncanHill (talk) 10:09, 16 May 2024 (UTC)[reply]
Non-English en-gb messages are nearly always somebody editing the wrong Translatewiki messages when trying to translate another language. Here translatewiki:User:Umar Ahmad2345 was trying to make Nupe (nup) which sounds amusingly like noob. It's not an option in our preferences but maybe it's coming. Incubator has a Nupe Wikipedia. PrimeHunter (talk) 11:09, 16 May 2024 (UTC)[reply]
Almost nothing is protected on translatewiki for messages, it's ripe for abuse. — xaosfluxTalk 13:30, 16 May 2024 (UTC)[reply]
Hi. One of my pastimes is trying to empty Category:Harv and Sfn no-target errors. Today I found Military courts of the United Kingdom, which has multiple uses of {{sfn|Armed Forces Act|2006}} which are meant to link to {{UK-LEG|title=Armed Forces Act 2006|path=ukpga/2006/52 |ref={{harvid|Armed Forces Act|2006}}}} but don't. I can't work out how to fix the no-target errors and get the link from sfn to citation template to work. Any help will be appreciated, thank you. DuncanHill (talk) 10:22, 16 May 2024 (UTC)[reply]
{{UK-LEG}} does not know about |ref= so does not create an anchor ID. Without an anchor ID, {{sfn}} has nothing to link to. Your options are to modify {{UK-LEG}} or implement an appropriate solution from the list of possible solutions at :Category:Harv and Sfn template errors § Resolving errors: {{wikicite}} (best) or {{anchor}} (not so best).
I got a bit confused at first because the instructions at :Category:Harv and Sfn template errors § Resolving errors only say "wrapping a plain-text citation inside {{wikicite}} and setting |ref= or |id= as appropriate to match the value expected by the short-cite template", whenwikicite can "be assigned templates as well as text". DuncanHill (talk) 22:53, 16 May 2024 (UTC)[reply]
ChristieBot, which manages GA nominations, has been crashing when trying to transclude the GA review to Talk:Israeli invasion of the Gaza Strip (2023–present). The error is "Page en:Special:Log is not supported due to namespace restriction". The page is extended-confirmed protected. The bot does have extended-confirmed rights as part of the bot group rights, but presumably is missing some other related permission. I can change the code to not crash and simply log the error, but I'm at work and won't be able to touch the code for a few hours. If anyone can tell me what the problem is I would appreciate it. Thanks. Mike Christie (talk - contribs - library) 12:48, 16 May 2024 (UTC)[reply]
@Mike Christie check your bot permissions grant, that you have enabled Edit protected pages. — xaosfluxTalk 13:33, 16 May 2024 (UTC)[reply]
Is this something I can set myself, and if so, where? (I'm not an admin.) I thought that a bot just needed the same user rights as a non-bot editor would need to edit a given page. Mike Christie (talk - contribs - library) 13:46, 16 May 2024 (UTC)[reply]
How is your bot logging in? Through the webui, or the api? If the API are you using a consumer grant or BotPasswords? — xaosfluxTalk 13:51, 16 May 2024 (UTC)[reply]
I don't have access to toolforge from where I am now, and since it was set up eighteen months ago I don't recall the details offhand, but as I recall I have a config set up in the toolforge shell account that handles the bot authentication. I think that means it uses BotPasswords? Mike Christie (talk - contribs - library) 14:04, 16 May 2024 (UTC)[reply]
@Mike Christie You'd have to check your PyWikiBot user-config.py file. If it has an authenticate[] = line you're using oauth, if it has a password_file = line you're using BotPasswords. --Ahecht (TALK PAGE) 14:08, 16 May 2024 (UTC)[reply]
I don't recall getting oauth to work so I think it must be BotPasswords, which I remember dealing with. (If SD0001 is available and has a moment they may be able to look and confirm as they are a maintainer for that bot.) Mike Christie (talk - contribs - library) 14:19, 16 May 2024 (UTC)[reply]
@Mike Christie If that's the case, you'd have to go to Special:BotPasswords, log in using your bot account, click on the password you're using for your bot, check the "Edit protected pages" box, and click "Update". --Ahecht (TALK PAGE) 14:36, 16 May 2024 (UTC)[reply]
It's using BotPassword. It should be able to edit the page if the appropriate grant is checked as mentioned above. But from the error message, I am wondering if there is a code issue as well - the bot seems to be literally trying to edit Special:Log which of course isn't possible. – SD0001 (talk) 17:58, 16 May 2024 (UTC)[reply]
That flag is now checked but it hasn't fixed the issue. The issue only occurs when trying to edit that page, using the same code that it uses for transcluding GA reviews on other talk pages, so I can't see why Special:Log is in the picture. There's certainly no explicit attempt by the bot to try to edit the special page. The error happens when it attempts to add text to the Page object's text field: in the traceback I see self.botMayEdit() is called, in pywikibot/page/_basepage.py, which eventually pops out to the Special:Log error for some reason. Later I will have time to add some code to trap the error so at least it'll finish its run, even if it can't do that particular transclusion. I'll do that this evening unless someone has any further ideas. Thanks for the help so far. Mike Christie (talk - contribs - library) 19:04, 16 May 2024 (UTC)[reply]
This appears to be an error in pywikibot, I can confirm it also occurs for me.
Full traceback
--------------------------------------------------------------------------- UnsupportedPageError Traceback (most recent call last) Cell In[1], line 4 2 site = pywikibot.Site('wikipedia:en') 3 page = pywikibot.Page(site, 'Talk:Israeli invasion of the Gaza Strip (2023–present)') ----> 4 page text = 'foo' File /srv/paws/lib/python3.10/site-packages/pywikibot/page/_basepage.py:576, in BasePage.text(self, value) 571 """Update the current (edited) wikitext. 572 573 :param value: New value or None 574 """ 575 try: --> 576 self.botMayEdit() # T262136, T267770 577 except Exception as e: 578 # dry tests aren't able to make an API call 579 # but are rejected by an Exception; ignore it then. 580 if not str(e).startswith('DryRequest rejecting request:'): File /srv/paws/lib/python3.10/site-packages/pywikibot/page/_basepage.py:1146, in BasePage.botMayEdit(self) 1131 """ 1132 Determine whether the active bot is allowed to edit the page. 1133 (...) 1143 user cnfig file (user-config.py), or using page.put(force=True). 1144 """ 1145 if not hasattr(self, '_bot_may_edit'): -> 1146 self _bot_may_edit = self._check_bot_may_edit() 1147 return self _bot_may_edit File /srv/paws/lib/python3.10/site-packages/pywikibot/page/_basepage.py:1163, in BasePage._check_bot_may_edit(self, module) 1161 username = self.site.username() 1162 try: -> 1163 templates = self.templatesWithParams() 1164 except (NoPageError, IsRedirectPageError, SectionError): 1165 return True File /srv/paws/lib/python3.10/site-packages/pywikibot/page/_page.py:78, in Page.templatesWithParams(self) 62 """Return templates used on this Page. 63 64 The templates are extracted by :meth:`raw_extracted_templates`, (...) 74 :rtype: list of (pywikibot.page.Page, list) 75 """ 76 # WARNING: may not return all templates used in particularly 77 # intricate cases such as template substitution ---> 78 titles = {t.title() for t in self.templates()} 79 templates = self raw_extracted_templates 80 # backwards-compatibility: convert the dict returned as the second 81 # element into a list in the format used by old scripts File /srv/paws/lib/python3.10/site-packages/pywikibot/page/_basepage.py:1612, in BasePage.templates(self, content) 1609 del self _templates 1611 if not hasattr(self, '_templates'): -> 1612 self _templates = set(self.itertemplates(content=content)) 1614 return list(self._templates) File /usr/lib/python3.10/_collections_abc.py:330, in Generator.__next__(self) 326 def __next__(self): 327 """Return the next item from the generator. 328 When exhausted, raise StopIteration. 329 """ --> 330 return self.send(None) File /srv/paws/lib/python3.10/site-packages/pywikibot/tools/collections.py:279, in GeneratorWrapper.send(self, value) 276 if not hasattr(self, '_started_gen'): 277 # start the generator 278 self _started_gen = self generator --> 279 return next(self._started_gen) File /srv/paws/lib/python3.10/site-packages/pywikibot/data/api/_generators.py:625, in QueryGenerator.generator(self) 622 self normalized = {} 624 try: --> 625 yield from self._extract_results(resultdata) 626 except RuntimeError: 627 break File /srv/paws/lib/python3.10/site-packages/pywikibot/data/api/_generators.py:567, in QueryGenerator._extract_results(self, resultdata) 565 """Extract results from resultdata.""" 566 for item in resultdata: --> 567 result = self.result(item) 568 if self _namespaces and not self._check_result_namespace(result): 569 continue File /srv/paws/lib/python3.10/site-packages/pywikibot/data/api/_generators.py:736, in PageGenerator.result(self, pagedata) 734 elif ns == Namespace.CATEGORY: 735 p = pywikibot.Category(p) --> 736 update_page(p, pagedata, self.props) 737 return p File /srv/paws/lib/python3.10/site-packages/pywikibot/data/api/_generators.py:983, in update_page(page, pagedict, props) 966 def update_page(page: pywikibot Page, 967 pagedict: dict[str, Any], 968 props: Iterable[str] | None = None) -> None: 969 """ 970 Update attributes of Page object *page*, based on query data in *pagedict*. 971 (...) 981 supported yet 982 """ --> 983 _update_pageid(page, pagedict) 984 _update_contentmodel(page, pagedict) 986 props = props or [] File /srv/paws/lib/python3.10/site-packages/pywikibot/data/api/_generators.py:882, in _update_pageid(page, pagedict) 880 raise InvalidTitleError(f"{page}: {pagedict['invalidreason']}") 881 if int(pagedict['ns']) < 0: --> 882 raise UnsupportedPageError(page) 883 raise RuntimeError(f"Page {pagedict['title']} has neither 'pageid'" 884 " nor 'missing' attribute") UnsupportedPageError: Page en:Special:Log is not supported due to namespace restriction.
Search results have a thumbnail next to them, or a gray placeholder if there's no suitable image in the article. Since today, those placeholders are bigger than regular thumbnails, which also places them uncomfortably close to the article text. It appears to be caused by this CSS rule:
.searchResultImage .searchResultImage-thumbnail > div {
padding: 0.5em;
}
Thank you for reporting. This is a bit of fallout from phab:T320295 and it should be fixed latest next week. —TheDJ (talk • contribs) 18:54, 16 May 2024 (UTC)[reply]
I don't think the talk page will get the comment any light, so I am putting it here. It does not require any discussion but a confirmation from technical person that it won't cause any issue. Thanks, ExclusiveEditorNotify Me! 10:51, 17 May 2024 (UTC)[reply]
Nothing you change in a "Template:XXXXXX/doc" page is going to break anything on other pages; worst case is it confuses someones that reads the documentation. — xaosfluxTalk 12:49, 17 May 2024 (UTC)[reply]
I have a sort of "hello, world" MediaWiki coding change I'd like to submit as my first-ever contribution to MediaWiki, and to get myself started and oriented with the system for submitting coding changes. If all goes well with that, I hope to follow that up with a more substantial change sometime, hopefully soon, after that. I already have a Wikimedia developer account, with accounts on MediaWiki and Wikitech. My usernames there, including my SSH access (shell) username, are the same as my English Wikipedia username. Now mw:Gerrit/Tutorial#Configure Git is telling me I need to have my "own Gerrit username". Is this a name which is unique to Gerrit, and not used anywhere else, such as the Toolforge? Also, I see on the Gerrit settings page a "Username" (is that the same as Git's "own Gerrit username"?), "Full name", and "Display name" – how are each of these used? Which of these names are used for the CREDITS page, the list that's updated by updateCredits.php? wbm1058 (talk) 20:35, 17 May 2024 (UTC)[reply]
Your Gerrit username is more properly your developer account username, which is the same as on Toolforge and other places. For those three fields, username is what you log in as, I don't think Full name is used anywhere, and display name is how your name appears on the Gerrit UI. updateCredits.php seems to parse "git log", so the name used is whatever shows up in Git, which usually is the same as one of the above but not necessarily. * Pppery *it has begun... 20:52, 17 May 2024 (UTC)[reply]
Full name is actually what's used for sign-ins via web UIs (Wikitech, Toolsadmin). "Username" is only used for SSH access (toolforge / git review). The CREDITS page uses the name from git log, which you'd set through the git config --global user.name command. – SD0001 (talk) 21:22, 17 May 2024 (UTC)[reply]
Thanks. Further complicating naming matters, I see there is an "LDAP" (Lightweight Directory Access Protocol) username. See wikitech:SRE/LDAP. Per wikitech:SRE/LDAP/Renaming users, "We do not rename users (Developer accounts) anymore. It can (and has) lead to various problems and errors all over the many separate systems which consume Developer accounts as their local databases and authentication methods will get out of sync." So I guess I'm stuck for now with the name I have (not that I want to change it). But a reason for proceeding cautiously here. I don't want to stumble into doing something irreversible that I wish I'd done differently later, after I figured out what I was actually doing, rather than signing up for it by trial and error. I don't recall seeing the mw:Developer account page before, and I think I created mine before the Create a Wikimedia developer account form was created. Today I just ran into the Bitu Identity Manager, which shows me "My LDAP properties". (see wikitech:IDM). Phabricator says my LDAP User is "Unknown". I don't know if there's a way I can personally make it known, or whether it being unknown is a problem. – wbm1058 (talk) 22:14, 17 May 2024 (UTC)[reply]
I think theres basically 2 logins. #1 is the oauth / centralauth / all wikis but wikitech one. #2 is ldap / gerrit / toolforge / wikitech. Lots of synonyms here. I forget if phabricator is one of those two, or a third one. –Novem Linguae (talk) 22:26, 17 May 2024 (UTC)[reply]
I suppose Phabricator is probably bilingual. Obviously I sign into it using my #1 because my #2 is unknown to the phabulous Phabricator. On the other hand, there must be some developers using it who may not have a #1. – wbm1058 (talk) 22:43, 17 May 2024 (UTC)[reply]
Yes, phab supports sign-in via either of the two. You can still link phab with the other account through Settings > External accounts. – SD0001 (talk) 06:21, 18 May 2024 (UTC)[reply]
Facepalm I looked at that screen twice and all I saw was date & time settings! Thanks! Now my account is linked with all (two) available providers. – wbm1058 (talk) 10:45, 18 May 2024 (UTC)[reply]
Shout-out to @BMueller (WMF):. I watched your online presentation given at last month's conference in Portland and thought you might be interested in reading this thread. Enjoyed meeting you in Toronto last year. – wbm1058 (talk) 23:21, 17 May 2024 (UTC)[reply]
Hmm, Gerrit is a Dutch male name meaning "brave with the spear", the Dutch and Frisian form of Gerard. And Gerrit (software) was authored by Google. Whereas Git was written by the guy behind Linux. Learn something new every day. wbm1058 (talk) 11:48, 18 May 2024 (UTC)[reply]
When asked why he called the new software, 'git', British slang meaning 'a rotten person', Torvalds said 'I'm an egotistical bastard, so I name all my projects after myself. First Linux, now git.' Ha! wbm1058 (talk) 12:00, 18 May 2024 (UTC)[reply]
Google is not part of the loop exactly. Google wrote the software, but it's open-source and the website https://gerrit.wikimedia.org is hosted by Wikimedia with no involvement from Google. * Pppery *it has begun... 13:23, 18 May 2024 (UTC)[reply]
More from the "I figured out what was happening only after it already happened" department. Wikimedia Code Reviewhttps://gerrit.wikimedia.org/r/settings says I registered @ Monday, May 13, 2024, 9:08:55 PM UTC-04:00 ... what? I don't recall doing anything specific to "register" there last Monday. What was I doing at that time? I thought per mw:Gerrit/Tutorial I had to configure Git in order to register for Gerrit, but here I am already registered for Gerrit, and I haven't configured Git yet! O I C. I think I was looking at a previous code review related to the task I'd decided to work on, when I noticed "Sign up" and "Sign in" links on the upper right corner of that page. Clicking "Sign up" took me to this new IDM "Create account" page to create a Wikimedia developer account. Hey, I thought, I think I already have one of those that I needed for Wikitech/Toolforge. So I left that page, and clicked "Sign in". Voila, my Wikitech password got me in. I thought I had simply logged into Gerrit, not registered for it. What I didn't realize was that the "Bitu Identity Manager" would not only sign me in, but register me as well! wbm1058 (talk) 16:12, 18 May 2024 (UTC)[reply]
I already have SSH keys set up for Toolforge at Toolsadmin which I use on PuTTY and WinSCP but not directly from the Windows command prompt.
mw:SSH keys seems to indicate that I can't use my Toolsadmin SSH but will need another one, set up from the Windows command prompt. Correct?
Also, regarding configuring Git personal information. The guide says "You should have to do this only once." Is that literally true, or does it mean once on my desktop and once on my laptop, if I have two machines that I might want to submit code from? wbm1058 (talk) 18:06, 18 May 2024 (UTC)[reply]
@Wbm1058 You can reuse the same SSH key across multiple projects (in this case toolsadmin and Gerrit). The tutorial assumes that you have not setup the keys before.
Regarding the configuration of Git, you will need to do it once per machine. Sohom (talk) 23:08, 18 May 2024 (UTC)[reply]
My desktop is still running Windows 7. I know, I know, long in the tooth, but I'm proud to have kept it going for 14 years and would like to make it to 15. It still works for me, for the most part. I've downloaded the production version MediaWiki 1.41.1 and have it running for debugging. I generated my SSH keys with PuTTYgen, since the Windows 7 command prompt does not support the ssh command. I suppose I'd need to use PuTTY on that machine to connect to Gerrit, as I use it to connect to the Toolforge bastion. I think I can figure that out; haven't found documentation on how to use Gerrit on a Windows 7 machine. I haven't set up SSH on my Windows 10 laptop yet (only do Toolforge from my desktop). I don't know how to copy my keys from PuTTY to the required location on Windows 10. Might be easier to generate new keys on Windows 10. I have an ssh-rsa key for Toolforge access; the documentation says to use the ed25519 type for optimum security and performance. Can I use different SSH keys on each machine? wbm1058 (talk) 16:53, 19 May 2024 (UTC)[reply]
As a matter of fact, you are kind of expected to use different keys per user per machine. That’s why all the ssh settings of toolforge and Gerrit allow you to add multiple public keys. —TheDJ (talk • contribs) 16:58, 19 May 2024 (UTC)[reply]
What TheDJ said, you are expected different SSH keys across machines. However, if you are using one machine, you can reuse the key across multiple things (I have mine on Github/Gitlab/Toolforge and Gerrit as well as a bunch of private services). Sohom (talk) 18:15, 19 May 2024 (UTC)[reply]
OK, thanks! New state-of-the-art ed25519 keys generated and installed for my Windows 10 laptop (which MSFT tells me will be unsupported after next year, and my hardware is too old to run Windows 11(.
"This clones the entire MediaWiki core repository, synced to the master branch, into a sub-directory named mediawiki"
I previously installed MediaWiki 1.40.1 on my laptop last November at the Toronto wikiconference, by downloading the then-current version from mw:Download, and successfully installed that, for testing.
I want to overwrite my previous 1.40.1 installation with the new files I just git got.
The standard mediawiki directory holds core and data sub-directories.
It doesn't appear that the git download includes any data. It appears to be a core directory, which includes some extra files that aren't part of the mw:Download version. Why don't the instructions say to download to a sub-directory named core rather than a sub-directory named mediawiki?
If using Git, export the files into a clean location, and then copy the old customized files into the new location as described in the previous section.
You will also need to install some external PHP libraries using Composer or a provided collection maintained for the Wikimedia wiki farm. More details on installing and updating external libraries can be found in the Git download documentation
So, for some reason, although I can test using 1.40.1 without having any PHP problems, I'll need to figure out this "Composer" thing in order to do development testing.
Hopefully it's not a problem that I'm running the PHP 8.2.12 Development Server – wbm1058 (talk) 23:11, 19 May 2024 (UTC)[reply]
I think all mediawiki unit tests are passing on php 8.1. Not sure about php 8.2. May want to switch to 8.1 to prevent hard to diagnose bugs. –Novem Linguae (talk) 00:45, 20 May 2024 (UTC)[reply]
The tests pass on php 8.2 as well [1], – SD0001 (talk) 12:16, 20 May 2024 (UTC)[reply]
mw:Manual:Installation requirements#PHP does not mention "Composer". It says "MediaWiki only requires PHP extensions that are enabled in PHP by default." I assume that's why I didn't get this error when I ran update.php on my desktop, where I'm just running the official MediaWiki releases. "If your hosting provider provides a basic LAMP environment without these, you may need to install or enable these manually."
I don't think submodules is what you need. The php maintenance/run.php update.php script just wants you to composer install in the mediawiki directory, that should download the required directories. Sohom (talk) 14:34, 20 May 2024 (UTC)[reply]
c:\php\mediawiki>composer update --no-dev
Composer could not find a composer.json file in c:\php\mediawiki
To initialize a project, please create a composer.json file. See https://getcomposer.org/basic-usage
I'm going to reboot my machine and try again. Composer install warned me that I might have a PATH problem. wbm1058 (talk) 15:56, 20 May 2024 (UTC)[reply]
Judging by your previous comments, you're just not in the directory that Composer expects – try going to c:\php\mediawiki\core, where you (and Composer) should find the composer.json file. Matma Rextalk 16:09, 20 May 2024 (UTC)[reply]
Yes, thanks, that was it. Once again the instructions misled me: "then run composer update --no-dev from your MediaWiki core directory." It's still running. This step takes significant time! wbm1058 (talk) 16:20, 20 May 2024 (UTC)[reply]
I think it worked. The console log is long, with a pile of "failed to download" warning messages, but it appears to have successfully worked around all of them. Here's the end of the log, showing just the last 3 of many installations:
- Installing wikimedia/timestamp (v4.1.1): Cloning 138f3099b4 from cache
- Installing wikimedia/xmp-reader (0.9.1): Cloning 8338d67969 from cache
- Installing zordius/lightncandy (v1.2.6): Cloning b451f73e8b from cache
44 package suggestions were added by new dependencies, use `composer suggest` to see details.
Generating optimized autoload files
11 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
> MediaWiki\Composer\ComposerVendorHtaccessCreator::onEvent
No security vulnerability advisories found.
I think I'm ready to try running update.php again. – wbm1058 (talk) 16:51, 20 May 2024 (UTC)[reply]
It's just that the way you have cloned the repo is unconventional. mediawiki/core should be cloned to a directory named "mediawiki", not "core". I think you will have a lot easier time going through mw:Local development quickstart instead, which unfortunately isn't advertised more prominently. You may want to discard the existing mediawiki install and use the quick start. You have already done step 1, so start with step 2. It's easy! – SD0001 (talk) 16:40, 20 May 2024 (UTC)[reply]
That "quick start" page has stuff I've already done previously, and insufficient info about stuff I needed to do.
I've had an "official release" version installed on my laptop since November. It makes a lot of sense to me to have started that way, because as complicated as installing the official release was, installing the developers' version is way more complicated yet.
I've had PHP installed directly on Windows for over a decade now. My bots use that.
There was no need for me to update my php.ini file to load the required PHP extensions. I already did that a long time ago. The problem is that this "composer" system basically "ignores" that, it seems to me.
It just says to "use Git" to clone the core, as if that's easy. No it wasn't. See above for what steps I went through to figure it out.
I installed SQLite already last year; I don't need to do that again.
I already knew how to start my server, though I was told by someone to use "localhost:80" in Boston in 2019, not "localhost:4000". I don't know whether it matters which number I use there.
What I need is a "quickstart" page for upgrading from an "official release" version to the developers' version. – wbm1058 (talk) 17:28, 20 May 2024 (UTC)[reply]
I Can't edit the Main Talk page so I'm posting here.
The main page (and it's talk page) seems to be stuck in full width mode even when I click on the full width toggle button in the bottom right corner. Other pages seem unaffected.
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0
In the Vector 2022 skin, main pages will be displayed at full width (like special pages). The goal is to keep the number of characters per line large enough. This is related to the coming changes to typography in Vector 2022. Learn more. [2]– robertsky (talk) 06:00, 18 May 2024 (UTC)[reply]
Just cross-posting here, I'm having some issues with one of the PERM scripts; discussion is here. Thanks! Primefac (talk) 07:43, 18 May 2024 (UTC)[reply]
Need help fixing the "second" sticky row in this table. With rowspan used in the first column, only the first row in rowgroup is sticky, the rest of the rows in individual rowgroups aren't. I assume it is a "sticky-col2" issue from Template:COVID-19 pandemic data/styles.css. Can it be fixed so it displays all rows in the second column unbroken when horizontally scrolling? Qwerty284651 (talk) 19:04, 18 May 2024 (UTC)[reply]
I have been using the dark mode gadget for a while now and I quite like it. I tried the native dark mode but I do not like it that much, as it is quite buggy and has a fair few contrast issues, see the phab board. Every time I load a page in namespaces outside of article space I get the message that informs me that I have two dark modes enabled and I need to choose one. When I go to disable the non-gadget dark mode it is not able to be disabled, are there any scripts to suppress this message, it is getting quite annoying. Thanks, v/r - Seawolf35T--C 00:03, 19 May 2024 (UTC)[reply]
I use this search query to see pages tagged for speedy deletion. For several days it has returned BBL Drizzy as a result even though that page is not tagged for deletion. The search results say it was last edited at 01:12 on 13 May 2024, which corresponds with Special:Diff/1223572833 (now in the history of Draft:BBL Drizzy). Purging or null-editing either the article or the draft will make it disappear from the results temporarily, but so far it's always come back shortly thereafter. Today I tried deleting and undeleting the pages, but this didn't help either. Any suggestions? (This query brings up strange results too, for what it's worth.) Extraordinary Writ (talk) 03:01, 19 May 2024 (UTC)[reply]
I don't experience this. BBL Drizzy is not a result for the first query, and the last query only brings up BBL Drizzy (last edited 19:04, 18 May 2024). – 2804:F1...7F:938A (talk) 03:15, 19 May 2024 (UTC)[reply]
Strange. The second query returns this for me, and some fiddling around at this site (pick Australia, Indonesia, India, etc.) suggests I'm not alone. Extraordinary Writ (talk) 03:40, 19 May 2024 (UTC)[reply]
I've been seeing some outdated search results also related particularly to a couple page moves that got done between when the search was crafted and when my fix was made. Particularly, in this search I'm seeing Draft:Peter the Great Interrogating the Tsarevich Alexei Petrovich at Peterhof and Draft:Ellen Webster Palmer when I hit one or another of the data centers (which I assume is at least part of the problem), but at least once I've gotten a search not to return those two, because neither are drafts any longer nor do either carry the problem that makes them show up in this search. Izno (talk) 20:36, 19 May 2024 (UTC)[reply]
The Appearance menu and new default standard font size will be available for logged-out users[edit]
Hi everyone! We are the Wikimedia Foundation Web team.
We work on making it easier to read Wikimedia projects as part of the objective "Reading and media experience" of the current year’s annual plan. To achieve this goal, we have introduced the "Accessibility for Reading" beta feature. It adds a menu which works on the Vector 2022 skin and allows logged-in users to choose different font sizes and color schemes based on individual needs.
The menu introduces a new Standard font setting. It slightly increases the size and height of the font. It was selected based on multiple sources. You will find more information on this in the section "About the new Standard font setting". As we announced last week, we are now ready to begin bringing some of these feature out of beta and making them available to more people.
What will change
We are now ready to make the new Appearance menu available for logged-out and logged-in users.
At the same time, we will also make the Standard option the new default for logged-out users only.
If no breaking technical issues are found, we plan on making this change within the next three weeks.
Later, this menu will also include the option to select dark mode, which for the time being will remain a beta feature. For more information, check out our project page.
About the menu
The new menu will allow logged-in and logged-out users to set preferences for:
Text size and line height (available now as the beta feature): Users will be able to choose between the Small (current default), Standard (recommended for better accessibility), and Large options. Selecting an option will change both the font size and line height of the text.
Dark mode (available now as the beta feature): Users will be able to choose to see the site in night mode on a permanent basis, or select an "automatic" setting which will set day or night mode based on the device or browser preferences.
Content width (previously available as a toggle button): We have moved the content width toggle from an icon at the bottom of the page to a labeled radio button in the new menu. It will work exactly the same as the toggle. The previous toggle button will no longer be available.
This menu has been tested as a beta feature by logged-in users across wikis as well as in user testing with readers. Based on the findings of these tests, we changed the menu to improve discoverability and ease of use, and to accommodate gadget compatibility.
The menu will appear to the right of the page, immediately under the Tools menu if that has been pinned. Unlike the Tools menu, the Appearance menu is pinned by default, but can be unpinned. Once unpinned, it collapses under an icon at the top of the page.
About the new Standard font setting
The "Small" option is the current default. We will be changing this default to "Standard" for logged-out users, while keeping "Small" as the default for logged-in users. The "Standard" and "Large" options were built and tested based on the following:
Academic studies and recommendations for the best average font size for the majority of readers. These recommendations stated that our current size is too small for the majority of people to read comfortably. This means that on average, people read more slowly, strain their eyes while reading, or have difficulty clearly seeing the text. Increasing the font size by default improves these issues for all users, including users who might not have sufficient time to spend adjusting a setting via the appearance menu or browser. Information density is also important, which is why we wanted to increase font size without sacrificing information density. We have achieved this by changing not only font size, but also line height and paragraph spacing.
Designs submitted by more than 630 Wikipedians from across 13 wikis of different languages, scripts, and sizes. The majority (~450) of these users opted for a font size that was larger than the default. "Standard" represents the average of the most popular cluster of responses (15-20 pixels). "Large" represents the need for an even larger option, as represented by the cluster of sizes between 21-26 pixels. You can read more on how we included volunteers in the process and landed on these options.
Beta feature usage showed that the majority of users who interact with the feature at least once opt for a font size that is larger than the current default.
Our works so far and next steps
Logged-in users will remain with the "small" setting for the time being as their default, but can change to any other setting at any time. In a few months, we will study how many logged-in users switch to standard and start a conversation on whether it makes sense for logged-in users to make the switch as well. From the early data from the beta feature, 55% of sessions who interacted with the feature chose to use a setting that was standard or larger.
If you'd like to help, we have a few simple requests for you:
Try out the new menu. Is anything confusing? Do you understand all the labels and how the menu works?
Try out the small, standard, and large sizes, the color schemes, and the width toggle. Reach out to us if you notice any bugs, or have questions or concerns.
If you'd like to learn more about the project, see our FAQ. Comments and questions are most welcome. Thank you! OVasileva (WMF) and SGrabarczuk (WMF) (talk) 13:58, 20 May 2024 (UTC)[reply]
